\chapter{类的结构--可维护性}

\section{需求}

继承让我们可以发散通用数据类型到更特殊化的类型并为我们节省重新编码基本功能。动态绑定帮助我们修复一个更通用的数据类型可能有的缺点。我们仍然需要的是一个干净的全局组织来简化维护一个大的类系统：

(1) 所有动态绑定需要指向正确的方法--例如，一个构建子不应当插入到类描述的错误位置；
(2) 我们需要一个条理分明的方式来添加、删除或者更改动态绑定方法对于从负累保证正确继承它的子类；
(3) 这里不应当有漏洞例如丢失动态绑定或者未定义方法；
(4) 如果我们继承一个动态绑定的方法，父类的实现必须保留绝对不更改，也就是说，实例必须可能只使用二进制信息；
(5) 不同类的集合应当可以具有不同集合的动态绑定方法--例如，只有Point和Circle在第四章中，但是不是第一章中的集合或者第三章和第五章中的表达式节点，使用了\verb|draw()|方法。

大多数情况下，这个列表预示着维护动态绑定是困难的和易错的--如果我们不能在实质上提高我们可能很好的创建无用的东西的情形。

到目前为止我们工作与一个单列表动态绑定方法，无论对于一个特殊类是否有意义。这个列表使用Struct Class定义并且被包含在动态绑定需要被实例化的地方。所幸有函数原型，ANSI-C将会检查函数名例如\verb|Point_ctor|满足类描述中的插槽，他们用作静态绑定初始化函数。上面的\verb|(1)|只是是否及格方法具有类型兼容接口或者是否我们改变struct Class并且做一些繁琐的重新编译的一个问题。

\verb|Item(2)|，改变struct Class，听起来像一个噩梦--我们需要手工访问每个类实现来更新类描述符的静态初始化，并且我们可以轻易的忘记添加一个新的方法在某些类中，这会引起问题\verb|(3)|。

5.6节中的计算器我们有一种优雅的方式添加赋值：我们改变源代码并且使得动态绑定的方法对于二元节点在3.6节中的公共因此我们可以重用他们作为初始化给Assign描述，但是这明显违背要求\verb|(4)|。

如果维护一个单独的struct Class已经听起来像一个挑战，上边的\verb|(5)|建议我们应当具有不同版本的struct Class对不同的集合类！这个要求是绝对合理的，然而：每个类需要一个构建子和析构子；对于点、圆和其他图形对象我们添加绘制功能；原子和字符串需要比较；集合像set、bag或者list有方法来添加、查找和删除对象；等等。

\section{元类}

需求\verb|(5)|

